The design and construction of a new or retrofit process (power, chemical, refinery or other) plant is incredibly complex and expensive, involving designers, engineers, and construction teams from many different companies and disciplines, all attempting to perform their work in parallel to get the plant built and up-and-running in the shortest time possible. Typically there is one entity responsible for the design, construction, and turnkey delivery of the plant to the end client: the Engineering Procurement Construction Contractor (EPC). The EPC subcontracts and manages individual suppliers, which includes the control system and operator training simulator providers.
The sooner the plant is up-and-running, the sooner the end client starts earning revenue on their production, sometimes easily totaling millions of dollars per day for a large plant. Thus, project incentives and penalties are used to motivate suppliers to accelerate schedule. For control system (and other) providers, the negative side of this is that the plant design can be “iterative” as multiple teams scramble to finish their work, leading to major system design revisions that potentially force rework. Depending on the contract structure, these rework costs are not always recoverable.
In addition to the plant control system, sometimes the overall contract calls for a plant Operator Training Simulator (OTS). The OTS, a process model married to the final control system, has a long development lead-time and must often wait for the plant physical design and control system to be complete before it itself can be completed. However, an OTS is often required significantly before the plant is in operation to allow enough time for training, and so is severely pinched by the other project constraints. Although minor players in terms of the total cost to build the plant, the control system and OTS are often very high risk factors to the plant owners. If they are not completed on time or are of poor quality, it could cost tens-of-millions of dollars of lost revenue while the problems are resolved. Performing a control system checkout on a full high-fidelity OTS has proven benefits of significantly increasing quality and performance.
Implementing a new control system (e.g., control, safety, fire and gas, etc.) of a process plant (e.g., power, chemical, refinery, etc.) is potentially extremely complex. However, the correct design of a new control system is critical to the safe and efficient operation of the process plant. Part of the implementation process involves validating the control system design. However validation of a design is difficult to accomplish prior to bringing a system online since validation depends on the process control elements sending and receiving valid stimuli to/from the physical processes that the control system is acting on. Additionally, the control system software for distributed control systems typically comprises thousands of control blocks and interface (I/O) points to the plant. Checking out the configuration and operation of the configured control system software during checkout can therefore be extremely time consuming.
FIG. 1 shows a typical hardware layout for a plant control system. For the purposes of the description of the illustrative embodiments, a control system potentially includes, in addition to a distributed control system, a safety instrumentation system, emergency shutdown system, fire and gas system, or any combination thereof. The control system uses control blocks to execute logical and mathematical functions to control the physical processes in the plant. These are configurable software blocks which are processed by the system's control processors (see, FIG. 1, control processors). An illustrative depiction of a set of control blocks is provided in FIG. 2. FIG. 2 shows a Manual/Auto station, which allows a control system operator to enter a desired process value when in Manual status, a Switch block, which selects between two inputs depending on an input mode, and a Follow/Hold block, which follows the input or “holds” in place, depending on an input mode. The illustrative control blocks respond to feedback stimuli/values (F3) from process instrumentation in the plant, and the blocks send their outputs (F1) to physical control devices (actuators, pumps, motors, etc.) in the plant. The communication to/from the plant instrumentation and actuators are via Input/Output modules (I/O modules), as shown in FIG. 1.
Proper operation of the control system depends upon the design and layout of the control blocks—a task generally assigned to a control system application engineer. While the control blocks can be created or based upon design best-practices, without the proper testing technology it can be difficult or even impossible to test process control logic for correct function until the system is installed in the plant. The inability to “pretest” process control logic potentially introduces a high risk element to a project for installing a new/redesigned process in a plant. The risks of installing process control logic without pre-testing/verification include financial hardships caused by project delays, damage to equipment, and injury to personnel. Application engineers perform simple tests of a process control system by simply emulating plant behavior, however in known test systems the quality of emulation is generally low, requires modifications to the process control system logic just to enable testing, and is time consuming to create. Illustrative examples of known test systems are summarized below.
Known methods for tieback-type testing (feeding back inputs to process control logic in response to control outputs provided by the control logic) of a distributed process control configuration require various arrangements of actual process control system hardware (e.g., control processors) to carry out testing. One type of tieback simulation (see, e.g., FIG. 3A) involves staging the entire hardware and software systems to be assembled, with tieback done by using actual wires or signal generators to loop output signals (representing signal values from a simulated process) back to input signals on an I/O module.
Another approach (see, FIGS. 3B and 3C) involves building simulation-type blocks within the actual control system software, and connecting the simulation blocks to the I/O software blocks. The approach depicted in FIGS. 3B and 3C does not require connection of input/output parameters of the control logic to actual (physical) I/O modules, however the control logic (including simulation blocks) is still loaded and run on real control processors. It is also necessary to modify the I/O software blocks to turn off the connection (see, FIG. 3B, AOUT and AIN I/O connections) to I/O hardware, and to reconfigure each block that is intended to connect to I/O hardware to accept inputs from a simulation block.
Another known approach (see, FIG. 3D) to simulation/testing uses commercially-available simulation software to provide simple process simulation. Like the second method, the I/O control blocks are modified to turn off their connections to physical I/O modules. Off-board simulation software, running for example on the operator's computer system, reads/writes to the I/O blocks via a special application program interface (API). This software potentially includes a quick configurator to connect simulator algorithms to a single input and output block based on an I/O block naming convention.
With regard to the aforementioned existing tieback simulation approaches: (1) all require actual control system hardware, including networking interfaces (the first method requires actual I/O modules); (2) the second and third methods require that the control system configuration be modified to turn off connection to physical I/O; and (3) all three methods have no mechanism for setting/resetting the control system and model states to a desired initial condition.
Dynamic process simulation is an invaluable tool for everything from validating the design of a process plant (power, chemical, refinery, etc.), as a tool to checkout the performance of the plant control or safety systems, and as an operator training simulator. However, several challenges are faced when providing a dynamic process simulation including: long development times, a need for highly-skilled simulation domain experts, the likely that a plant and/or control system design will evolve while a simulator design/configuration is in development—which leads to reworking the simulation, an actual plant size (and associated control system) is often immense—which requires a large team to build and configure process models; a process design can include descriptions from disparate data sources including equipment data sheets, piping and instrumentation diagrams (P&IDs) showing the layout of a plant process, and instrumentation lists.
Many process control systems, such as those implemented in power plants or petroleum refineries, need to be checked for correct design, configuration, and connection before deployment. Failure to do so could result in plant malfunctions that potentially lead to inefficient performance, damage to plant equipment or injury to personnel.